perm filename MAFFIX.PUB[HAL,HE]1 blob sn#127023 filedate 1974-10-29 generic text, type T, neo UTF8
.att: NEWSS ATTACHMENT

	Assembly often involves affixing  one object to another.  HAL
has a mechanism to automatically keep  track of the location of  a
subsidiary piece of the assembly as its  base is moved; the mechanism
is  called attachment.   For example, there  might be  a frame called
PUMP and a  frame called BASE.   At some stage  in the assembly,  the
pump  is bolted  to the  base.   At this  time it  is appropriate  to
include the statement 
.UNFILL
	ATTACH PUMP TO BASE
.REFILL
 The  effect of  this is  severalfold: It  informs the compiler  that
motions of BASE  are to affect the location of PUMP, it generates the
assertion 
.UNFILL
	ASSERT FACT (ATTACHED PUMP BASE)
.REFILL
 and  it  causes code  to be  generated  for the  runtime which  will
automatically  update the value of  PUMP every time  BASE is changed.
Please note  that the  ATTACH statement  does not  act  as a  library
routine invocation; it does not generate code to actually perform the
bolting operation.   The statement merely informs the HAL system that
at  this stage  in  the  execution of  the  program,  PUMP is  to  be
considered attached to BASE.

	If PUMP  should be moved while attached to BASE, the value of
BASE itself will not change,  but the attachment will remain  for the
new relative positions of PUMP  and BASE.  Occasionally it is desired
that the attachment be symmetric, so that motion of either frame will
cause the other to move.  This is done by including the reserved word
RIGIDLY in the attach statement: 
.UNFILL
	ATTACH PUMP TO BASE RIGIDLY
.REFILL
A more precise definition of attachment in terms of graph structures
is given in {sssref  gat}.  Here, we should point out that the
system uses a trans to store the relative positions 
(in our example, "(BASE α→ PUMP)" ) of the 
attached frames.  Normally, the system would invent a 
temporary variable to hold this trans; however, the user can 
supply her own variable to be used instead, thus allowing her
to modify directly the attachment relation.  This is done by including
the phrase "BY <transform variable id>" in the ATTACH statement.
For instance,
.UNFILL
	ATTACH PUMP TO BASE BY T1;
.REFILL
	If the value of  the trans is modified  in a non-rigid  (that
is,  assymetric)  attachment,  the  effect is to move  the subsidiary
frame.   If  the value  of the  trans  changes in  a rigid  
(symmetric) attachment, then neither frame will change its value until
one of them  explicitly gets a new value; at that time the other will spring
to a new position, as determined by the trans.

The inclusion of the construct "AT <transform expression>" will cause
HAL to use the indicated value for the relative attached position of the
objects.  Thus,

.UNFILL
	ATTACH PUMP TO BASE AT [(0,0,0)|(0,0,0)]

.bull
is equivalent to

	ATTACH PUMP TO BASE BY TEMPXF;
	TEMPXF α← [(0,0,0)|(0,0,0)]
.REFILL
	It  is  possible to  make  chains of  attachments,   possibly
involving some rigid attachments and some non-rigid ones.


Attachments are undone by the DETACH statement.  For example,
.UNFILL
	DETACH  PUMP  FROM BASE
.REFILL
will remove the attach structure between PUMP and BASE,  and will discard
the invented trans  (unless it was named, of course).  Two changes in
the compiler's assertional data base will also  be generated
(See the section on assertions):

.unfill
	DENY  FACT  (ATTACHED  PUMP BASE);
	ASSERT FACT (WAS_ATTACHED PUMP BASE)
.REFILL

The latter assertion
is  used in calculation of default  deproach points. A side-effect of
any  assignment,  like F1  α←  <value>,  is  
.UNFILL
	DENY FACT (WAS_ATTACHED ANYTHING F1);
	DENY FACT (WAS_ATTACHED F1 ANYTHING)     .
.REFILL